$ type BLS32043.RELEASE_NOTES











                              CHAPTER 1

                     VAX BLISS V4.3 RELEASE NOTES




This document contains information about VAX BLISS-32 Version 4.3  and
previous versions.

This document is organized into four chapters:


      o  Chapter 1 provides an overview of this file.

      o  Chapter   2   provides    information    on    compatibility,
         restrictions, and documentation errors.

      o  Chapter 3 provides information on new features.

      o  Chapter 4 provides a list of the maintenance  fixes  included
         in the VAX BLISS-32 V4.3 compiler.























                                 1-1












                              CHAPTER 2

                         COMPATIBILITY NOTES




This chapter describes the differences between  VAX  BLISS-32  Version
4.2  and  Version  4.3.   It also describes all known restrictions and
documentation errors.



2.1  COMPATIBILITY

This section describes the compatibility between VAX BLISS-32  Version
4.2 and the new Version 4.3.



2.1.1  Source Compatibility

The source language accepted by the VAX BLISS-32 Version 4.2  compiler
is  upwardly  compatible  with  that  accepted  by the new Version 4.3
compiler.



2.1.2  Object Compatibility

The object files produced by the VAX BLISS-32 Version 4.2 compiler are
upwardly  compatible  with  the Version 4.3 object files.  They can be
mixed freely in the same executable image.



2.1.3  Image Compatibility

The images linked with VAX BLISS-32 V4.3 object modules  are  strictly
compatible with similar images using V4.2 modules.





                                 2-1
























COMPATIBILITY NOTES
COMPATIBILITY


2.1.4  Library Files

The library files produced by a VAX BLISS-32 Version 4.2 compiler will
be accepted by the VAX BLISS-32 Version 4.3 compiler.



2.1.5  Behavior Differences

There are several differences in behavior that you  will  notice  when
migrating  from  a  VAX  BLISS-32 Version 4.2 compiler to VAX BLISS-32
Version 4.3:


     o  Obsolete BCREF  and  /MASTER  qualifier  -  The  VAX  BLISS-32
        Version  4.3 compiler no longer accepts the /MASTER qualifier.
        With the addition of support for the VAX Source Code Analyzer,
        the BCREF utility will be obsolete.  Please see the chapter on
        "New Features" for more information about this new feature.

     o  no XPORT  -  XPORT,  which  was  previously  provided  on  the
        BLISS-32  kit  but  was unsupported, has been removed from the
        kit.  It is now available through the DECUS Program Library.





2.2  KNOWN RESTRICTIONS

This section includes all  known  restrictions  in  the  VAX  BLISS-32
Version  4.3  compiler.   Where possible, temporary solutions to these
restrictions are provided.




PROBLEM:  When compiling  a  module  containing  a  general  structure
          reference  whose segment expression is a UPLIT or PLIT, such
          as:

                X = .VECTOR[ UPLIT(0, 1, 2), .Y ; ,LONG ];

          the compiler will issue an Internal Compiler Error 4006.









                                 2-2





















                                                   COMPATIBILITY NOTES
                                                    KNOWN RESTRICTIONS


SOLUTION: The workaround for this problem is to either compile /NOANA,
          or to change the source file such that the UPLIT is not used
          as the structure base address.  A workaround for  the  above
          example would be:

              LOCAL
                Vec : VECTOR[3,LONG] INITIAL (0,1,2);
              ...
              X = .Vec[.Y]

          This problem will be corrected in a future  release  of  VAX
          BLISS-32.




PROBLEM:  The following code fragment:

                d = 0;
                .....
                WHILE .d NEQ 0 DO
                    BEGIN
                    ....
                    x = 66 / .d;        ! Assume "d" never written
                    ...
                    IF .y THEN EXITLOOP
                    END

          will cause a zero-divide  exception  during  execution  when
          compiled  with  normal  optimization.  The compiler believes
          that the expression "66/.d" is loop invariant and moves  the
          computation out of the loop.

SOLUTION: In this particular case, the expression can be rewritten as:

                WHILE 1 DO
                    BEGIN
                    .....
                    IF .d EQL 0 THEN EXITLOOP;
                    ....
                    x = 66 / .d;
                    .....
                    END;

          In this case, the expression cannot  be  moved  out  of  the
          loop.




PROBLEM:  Incorrect code generated for structure  definitions  of  the


                                 2-3





















COMPATIBILITY NOTES
KNOWN RESTRICTIONS


          form:

                STRUCTURE BAD[I,P,S]= [%UPVAL]
                    (IF .I THEN BAD ELSE BAD + .BAD<16,16>)<P,S>;

                OWN X: BAD[];
                LOCAL T;

                T = .X[.T,0,12];

          "X" is loaded into a register in the  THEN-branch,  but  the
          ELSE-branch uses the register without loading it.

SOLUTION: This is the result of a design flaw  in  the  way  structure
          references  are  expanded.  BLISS semantics guarantee that a
          structure actual-parameter is evaluated only once.  This  is
          implemented  by treating the first occurrence of a structure
          formal  as  if  it  were  a  BIND  declaration.   The  other
          occurrences  of  the structure formal are then treated as if
          they were uses of the "imaginary" bind-name.  This choice of
          implementation  fails  when  the  first  occurrence  of  the
          structure formal is in conditional flow.  The problem can be
          avoided by ensuring that the first occurrence of each formal
          is outside  of  conditional  flow.   The  example  structure
          should be written as:

                STRUCTURE GOOD[I,P,S] = [%UPVAL]
                (GOOD; IF .I THEN GOOD ELSE GOOD + .GOOD<16,16>)<P,S>;

          Note that  the  "structure-name"  is  the  zeroth  structure
          formal parameter.  The formals "I", "P", and "S" are already
          outside  of  conditional  flow,  so   they   are   processed
          correctly.   This  change  will  cause  the  compiler to use
          slightly  more  memory,  but  the  resulting  code  will  be
          correct.  There also should be no reduction in optimization.

          Be aware that no problem will  occur  when  the  conditional
          flow is constant folded at compile time, or when there is no
          conditional flow in the structure body.














                                 2-4





















                                                   COMPATIBILITY NOTES
                                                    KNOWN RESTRICTIONS


PROBLEM:  The following code fragment:

                STRUCTURE
                    s1[] = [1] s1,
                    s2[] = [1] s1[s2];
                GLOBAL ROUTINE  r (x : REF s2) = x[];

          will cause an internal compiler error to occur.

SOLUTION: Like the previous problem, this is a design flaw in the  way
          structure  references  are  expanded.   When  one  structure
          references another structure within a structure declaration,
          bindings  become  indeterminate  during  evaluation  of  the
          structure reference.  The solution is to avoid  the  use  of
          such constructs in your program.




PROBLEM:  If  uninitialized  variable  checking  is  in  effect,   the
          compiler  occasionally  generates  spurious  messages when a
          variable is initialized in one branch of  an  IF,  CASE,  or
          SELECT  in  a  loop  and  then  referenced  in another.  For
          example:

                LOCAL X, FIRST_TIME,...;
                    FIRST_TIME = 1;
                WHILE condition
                DO
                    BEGIN
                    IF .FIRST_TIME
                    THEN
                        X = 0
                    ELSE
                        X = .X + 1;
                    FIRST_TIME = 0;
                    . . .
                    END;

          The compiler will report that X is uninitialized in "X =  .X
          + 1".

SOLUTION: The  simplest  and  best  solution  is  to  initialize  such
          variables  before  they appear in the loop.  You can do this
          with an assignment or by using an INITIAL attribute  on  the
          variable declaration.

          You can also suppress  uninitialized  variable  messages  by
          using  the  /CHECK =NOINIT qualifier on the compiler command
          line.



                                 2-5





















COMPATIBILITY NOTES
DOCUMENTATION ERRORS


2.3  DOCUMENTATION ERRORS

This section includes all known  documentation  errors  in  the  BLISS
Language Reference Manual and the VAX BLISS-32 User Manual.

     o  No known errors




2.4  DOCUMENTATION OMISSIONS

This section includes all known omissions from the documentation.

There is only one known omission:  two error messages are missing from
Appendix E of the VAX BLISS-32 User Manual.

     o  Missing error message NOTUSEDCONF.

        269 Usage of register <integer> conflicts with NOTUSED
            definition in routine's linkage


            Explanation:  There is a conflict between  the  use  of  a
            register  in  a  REGISTER  or  BUILTIN declaration and the
            current routine's user-defined linkage, which defines  the
            register as NOTUSED.

            User Action:  Either remove the register's number from the
            NOTUSED  list,  or  use  another  register  number  in the
            REGISTER or BUILTIN declaration.

     o  Missing error message RETREGCONF.

            270 Valued routine's linkage should not define
                value-return register <integer> as NOTUSED


            Explanation:  There is a conflict between the  declaration
            of  a  valued  routine  and its linkage, which defines the
            value-return register as NOTUSED.

            User  Action:   Remove  the  register's  number  from  the
            NOTUSED list.









                                 2-6












                              CHAPTER 3

                             NEW FEATURES



3.1  SUPPORT FOR SOURCE CODE ANALYZER

Support for VAXSCA, the VAX Source Code Analyzer, has been added  with
this   release  of  BLISS.   VAXSCA  is  an  interactive  source  code
cross-reference and static analysis tool to aid  in  code  development
and  maintenance.   This  tool's  scope  includes  an entire system as
opposed to the individual modular constituents of that system.  VAXSCA
aids  in  dealing  with  the  global  interdependencies of the overall
system and the inherent complexity  of  these  dependencies  in  large
multi-module software.

VAXSCA fits into a  highly  integrated  environment.   It  is  tightly
coupled  with  the VAX Language Sensitive Editor to provide windows on
the sources of the system.  Using the Language Sensitive Editor  as  a
means of access to the user's source provides powerful and easily used
source navigation and editing aids.

The BLISS compiler generates  source  code  analysis  files  when  the
/ANALYSIS_DATA  qualifier  is  specified  on the command line.  If the
file-spec is not specified, the default file name is the same  as  the
source program; the default file type is ".ANA".  Once the source code
analysis files are loaded into an SCA library, the VAXSCA tool can  be
used  to  obtain  information  about  global  interdependencies of the
overall system.

The following provides brief  descriptions  of  the  key  features  of
VAXSCA.



3.1.1  Cross-Referencing

The cross-referencing query features  of  VAXSCA  provide  information
about  program symbols and source files.  Cross-reference features are
provided by the FIND command, and allow you to:




                                 3-1






NEW FEATURES


      o  Locate names and the occurrences of names

      o  Query a specified set of names or  partial  names;  wildcards
         are permitted

      o  Limit a query to specific characteristics (such  as  variable
         names or source files)

      o  Limit a query to specific occurrences (such  as  the  primary
         declaration of a symbol or occurrences of a file)




3.1.2  Static Analysis

The analysis query features of VAXSCA provide  structural  information
relating  to  your program or, more specifically, the interrelation of
symbols and files.  Static analysis is provided by the  VIEW  CALLTREE
and CHECK CALL commands.

      o  The VIEW CALLTREE command allows you to display routine  call
         relationships relative to a specified routine.

      o  The CHECK CALL command allows you to  analyze  routine  calls
         for consistency, with specific regard to the numbers and data
         types of arguments passed and the types of values returned.




3.1.3  VAXLSE Integration

Integration with VAXLSE provides for multimodule cross referencing and
analysis  through  the  use of multiple query buffers.  These features
allow you to gain access, within a single editing session, to  any  or
all  of the modules and files comprising a software project.  They not
only expand your analysis capabilities but further speed and  simplify
your development and maintenance tasks.















                                 3-2












                              CHAPTER 4

                MAINTENANCE CORRECTIONS FOR VAX BLISS



This chapter describes all changes made for the V4.3  release  of  the
VAX  BLISS-32  compiler.  It summarizes all corrections made as of the
date the kit was built.



      o  The BLISS-32 compiler could incorrectly remove an instruction
         when   applying   an   optimization   to  two  BISx  or  BICx
         instructions whose operands were post-incremented:

             BICLx  ...(R0)+...
             BICWx  ...(R0)+...

         The second instruction was  incorrectly  removed  in  certain
         circumstances.  This problem has been fixed.


      o  The module name has no meaning within the body of the module.
         The  behaviour  of  %DECLARED with respect to the module name
         was corrected, and uses of the module name no longer can lead
         to internal compiler errors.


      o  Both the BLISS-32 and the BLISS-16 compilers  could  generate
         an internal compiler error during Flow Processing for certain
         programs due to an attempted optimization on a program of the
         following form:

         routine x ( aa ) : novalue =
             begin
             bind a = .aa : ref vector;
             local b;
             
             a[0];
             a[1];
             while b do
                 if b 


                                 4-1






MAINTENANCE CORRECTIONS FOR VAX BLISS


                 then
                     a[1]
                 else
                     a[2];
             end;

         This problem has been fixed.


      o  The CVTRGL and CVTRHL built-ins were incorrectly  treated  by
         the  BLISS-32  compiler as not returning a value as specified
         in the BLISS-32 User's Guide.  This problem has been fixed.


      o  The BLISS-32 compiler got an access violation when  compiling
         the following program:

             MODULE Test =
             BEGIN
             STRUCTURE X = Y;
             END ELUDOM

         This problem has been fixed.


      o  The BLISS-32 compiler generated incorrect code when compiling
         a  larger  program  containing  the  following else-if nested
         within a case:

             else
                 if cmpf(xh, b__xl) lss 0 or
                    cmpf(xl, b__xh) gtr 0 or
                    cmpf(yh, b__yl) lss 0 or
                    cmpf(yl, b__yh) gtr 0
                 then
                    ...

         In the generated code, the SOBGTR instruction after the first
         CMPF  branches  to  the  wrong  label.  This problem has been
         fixed.


      o  Support for  VAXSCA  added  to  both  the  BLISS-32  and  the
         BLISS-16  compilers.   The /ANALYSIS_DATA qualifier specifies
         whether or not the compiler should generate a file containing
         source  code  analysis  information.   If  the  file-spec  is
         omitted, the default file name is  the  same  as  the  source
         program;    the    default    file    type   is   ANA.    The
         /MASTER_CROSS_REFERENCE  qualifier  is  no  longer  a   valid
         qualifier.




                                 4-2





















                                 MAINTENANCE CORRECTIONS FOR VAX BLISS


      o  The BLISS-32 compiler generated incorrect code  by  illegally
         re-using  a non-destroyable (global) register for calculating
         ABS or SIGN.  This problem has been fixed.


      o  In  both  the  BLISS-16   and   BLISS-32   compiler-generated
         listings,  lines  containing just a form-feed are now counted
         (but not printed).


      o  The BLISS-32 and  BLISS-16  compilers  got  reserved  operand
         faults  when  more  than the maximum allowed number of psects
         were used in a single module.  This has been fixed by  adding
         a check for exceeding the implementation limit of psects used
         per module  and  generating  an  E-level  message  if  it  is
         exceeded.


      o  BLISS-32 generated code to 'ENABLE' a condition  handler  was
         associated  with  an  incorrect  source  line  number.   This
         confused VAX PCA when it attempted to set breakpoints.


      o  In both the BLISS-32 and the BLISS-16 compilers, two problems
         related  to  the  use  of  negative  values  for  the  length
         parameters of CH$  functions  have  been  fixed.   The  first
         problem was that compiling the statement:

             Ch$Fill( 0, -3, X);

         caused a reserved operand fault.  The second problem was that
         compiling the statement:

             Ch$Copy( 1, X, 0, -3, Y);

         gave the warning message "Length of destination shorter  than
         sum of source lengths in CH$COPY".


      o  (SPR 11-92893) Internal Compiler Error 6011 could occur  when
         compiling  a  routine  containing  a complex series of BINDs.
         This problem has been fixed.


      o  When the VOLATILE attribute was used on a structure, only the
         first  longword  of  the  structure  was treated as VOLATILE.
         This problem has been fixed.


      o  An  Internal  Compiler   Error   was   generated   when   the
         implementation  limit  of  64  dynamic  stack temporaries was
         exceeded.  This has been changed to issue an  "Implementation


                                 4-3





















MAINTENANCE CORRECTIONS FOR VAX BLISS


         limit exceeded" message.


      o  When compiling a VERY large  program,  an  Internal  Compiler
         Error  message  was  generated with a number around 500.  The
         cause of the error was an overflow of the "complexity"  value
         for  the routine being compiled.  The compiler now checks for
         overflow of this internal value and generates a more specific
         error message.


      o  Disable informational message for  redeclared  BUILTINs  when
         using /CHECK:REDECLARE.


      o  Incorrect  code  could  be  generated  due  to   an   illegal
         optimization.    The   compiler   failed  to  note  that  the
         assignment below makes re-use of the result of the top  "AND"
         illegal at the second "AND".

             <expr1> AND <expr2>
                                :
             <assignment to element of expr2>
                                :
             <expr1> AND <expr2>
             
         This problem has been fixed.


      o  Update the offset of the second  longword,  third,  and  etc.
         for SUBM's operand.


      o  The number of psects allowed per module  has  been  increased
         from 256 to 32768.


      o  More consistency  checks  are  now  performed  for  registers
         defined as NOTUSED in a user-defined linkage.  In particular,
         if a NOTUSED  register  is  declared  in  a  routine  with  a
         REGISTER  or  BUILTIN  declaration, a warning message will be
         issued.  If a valued routine is declared with a linkage which
         defines  the value-return register (R0) as NOTUSED, a warning
         message will be issued.










                                 4-4

$